Aug 94 Top 10
Volume Number: 10>replyPtr Issue Number: 8>replyPtr$ Column Tag: Think Top 10>replyPtra Think Top 10 
>replyPtrt &By Symantec’s Technical Support Team>replyPtr $LThis is a monthly column written by Symantec’s Technical Support Engineers>replyPtr Jintended to provide you with information on Symantec products. Each month we cover>replyPtr 1either a specific application of tools or a “Q&A” list.>replyPtr KQ. Can SourceServer be used successfully with a Visual Architect project?>replyPtrSA. It can. However, Visual Architect is not currently SourceServer “savvy” . Here>replyPtr $@are some guidelines for a peaceful coexistence between the two:>replyPtr‡ORule #1: Check out necessary Visual Architect files BEFORE Generating. Since VA>replyPtrÏ$Kdoes NOT honor SourceServer’s 'ckid' resources, it will go ahead and overwrite>replyPtr¯$Pfiles that have been checked out as read-only. So before you Generate from Visual>fixBtnName$HArchtitect, make sure you’ve checked out any files that will be modified,>fixBtnName$Sotherwise you WON’T to be able to check the revisions back in. This goes for the>replyPtr $%Visual Architect.rsrc file, as well.>replyPtr WRule #2: Close the Visual Architect.rsrc file before checking it in or out. A Visual>replyPtr $LArchtiect.rsrc file’s 'ckid' resource that is modified by SourceServer while the>fixBtnName@$Wfile is open will NOT be saved when the file is closed. The file won’t be able to be>replyPtr $checked in or out after this.>fixBtnNamed$SIf you forget to follow either of these rules, you may be able to set things right>replyPtr Nagain by issuing the appropriate OrphanFiles, Undo Checkout, or DeleteRevisions>fixBtnName| commands. But this is not fun.>fixBtnName $OStrong Suggestion: Set up nested ProjectorDB’s to separate Generate-Once and>replyPtr -Generate-Many and non-Visual Architect files. >replyPtr $NCurrently VA is rather inflexible about where it puts its generated files. You get>fixBtnName Nexactly one choice: all go in a folder named “Source” in your project folder, and>fixBtnName Qsub- folders are ignored. You can, however, use nested ProjectorDB’s to bring some>replyPtr Torder to this ungainly group of files, and at the same time avoid the performance hit>fixBtnName Hwhich would be incurred from storing all those files in the same ProjectorDB.>fixBtnName‹$LThe key difference among the files in the VA “Source” folder is whether they are>fixBtnNameË Rgenerate-once or generate-many. For the most part, this means lower-layer versus>fixBtnNameÙ Uupper-layer files, but it’s important to be aware that a number of other files, such as>replyPtrcustomGetFileTReferences.cp and the Items.h files, are also generate-many. Since you’ll haveapplication Q to check out some, if not all, generate-many files each time you Generate, and then>replyPtr Ncheck them back in, it makes sense to group these files into a sub-project (“VAapplication$ VRegenerated Files”, for instance). Note that your VA.rsrc file should also be checkedapplication0 Sinto this sub-project. The rest of the files in the “Source” folder will go in another>replyPtr< Osub-project (call it “VA One-Time Files”), and finally your non-VA files could go>replyPtrH Teither into the top-level project, or into a
>replyPtrt &By Symantec’s Technical Support Team>replyPtr $LThis is a monthly column written by Symantec’s Technical Support Engineers>replyPtr Jintended to provide you with information on Symantec products. Each month we cover>replyPtr 1either a specific application of tools or a “Q&A” list.>replyPtr KQ. Can SourceServer be used successfully with a Visual Architect project?>replyPtrSA. It can. However, Visual Architect is not currently SourceServer “savvy” . Here>replyPtr $@are some guidelines for a peaceful coexistence between the two:>replyPtr‡ORule #1: Check out necessary Visual Architect files BEFORE Generating. Since VA>replyPtrÏ$Kdoes NOT honor SourceServer’s 'ckid' resources, it will go ahead and overwrite>replyPtr¯$Pfiles that have been checked out as read-only. So before you Generate from Visual>fixBtnName$HArchtitect, make sure you’ve checked out any files that will be modified,>fixBtnName$Sotherwise you WON’T to be able to check the revisions back in. This goes for the>replyPtr $%Visual Architect.rsrc file, as well.>replyPtr WRule #2: Close the Visual Architect.rsrc file before checking it in or out. A Visual>replyPtr $LArchtiect.rsrc file’s 'ckid' resource that is modified by SourceServer while the>fixBtnName@$Wfile is open will NOT be saved when the file is closed. The file won’t be able to be>replyPtr $checked in or out after this.>fixBtnNamed$SIf you forget to follow either of these rules, you may be able to set things right>replyPtr Nagain by issuing the appropriate OrphanFiles, Undo Checkout, or DeleteRevisions>fixBtnName| commands. But this is not fun.>fixBtnName $OStrong Suggestion: Set up nested ProjectorDB’s to separate Generate-Once and>replyPtr -Generate-Many and non-Visual Architect files. >replyPtr $NCurrently VA is rather inflexible about where it puts its generated files. You get>fixBtnName Nexactly one choice: all go in a folder named “Source” in your project folder, and>fixBtnName Qsub- folders are ignored. You can, however, use nested ProjectorDB’s to bring some>replyPtr Torder to this ungainly group of files, and at the same time avoid the performance hit>fixBtnName Hwhich would be incurred from storing all those files in the same ProjectorDB.>fixBtnName‹$LThe key difference among the files in the VA “Source” folder is whether they are>fixBtnNameË Rgenerate-once or generate-many. For the most part, this means lower-layer versus>fixBtnNameÙ Uupper-layer files, but it’s important to be aware that a number of other files, such as>replyPtrcustomGetFileTReferences.cp and the